By way of background concerning some conventional systems, access to data resources and/or operations of a protected system via an access control system has traditionally been achieved by assigning one or more access privileges to one or more users of the protected system. In this regard, conventional role based access control (RBAC) techniques enable a user to access protected system resources based on a role assigned to the user. As such, the user is permitted to access and/or perform operations on the protected system based on one or more access privileges assigned to the role. For example, protected system operations (in this case a storage system being the protected system) such as “create storage volume” and “delete storage volume” can be assigned to an “administrator” role. When the user is assigned the administrator role, the user can create and/or delete any storage volume included in the storage system.
RBAC is thus an approach to restricting system, or system resource, access to authorized users based roles and permissions defined for the roles. Within an organization, roles are created for various job functions, such as manager or administrator. The permissions to perform certain operations are assigned to specific roles. Members of staff or other system users are assigned particular roles, and through those role assignments, those user(s) acquire the permissions to perform particular system functions. Since users are not assigned permissions directly, but through their role (or roles), management of individual user rights becomes a matter of assigning appropriate users to appropriate roles. Typically, a role is represented as an identifier (role name or ID) and a list of role member IDs, e.g., users or groups stored as security identifiers (SIDs) in Windows-based systems or user entity names in Unix-based systems.
To supplement the role assignments, in a conventional access control list (ACL) model, objects or resources can be assigned a set of role IDs that describe the effective set of users for which access to the objects or resources can be granted. Typically, in operation, based on the user context of a user making a request for an operation or a resource, i.e., based on what roles the user is allowed to assume, and based on what permission set those roles resolve according to the access control list (ACL) enforced over a given object or resource being accessed, the system makes a determination of whether the action being taken by the given user is permitted. In this regard, both the set of roles that a user can assume and the set of permissions defined over an object for given roles are purely declarative and therefore statically defined. While this is generally sufficient for a system or a hierarchy of resources of a known extent and scale, when the number of users and types of roles and relationships between them become non-trivial, or change frequently, statically defining the access permissions and user roles and keeping them up to date and consistent with changing resources and resource hierarchies can present a burdensome security configuration management challenge.
In this regard, traditional access control administration models are based on objects whereby access control is specified at the object or object container (for example, in an ACL), and typically an administrator or other authorized entity specifies permissions granted to the object. Administrators thus translate the organizational authorization policy into permissions on objects: Each object has a list of access permissions that is granted to roles representing various users and groups within an organization. Compared to the situation of having to define custom code for controlling permissions for a given data system, RBAC simplifies access control administration and increases manageability in enterprise environments by allowing permissions to be managed in terms of user job functions.
Some of the goals of role-based access control can be accomplished using groups. A group corresponds to an employee role, and application administrators can specify the permissions that are needed by the role by granting the group permission in an ACL for the object. As object collections grow, however, the number of places where administrators manage permissions grows. Diligent use of resource groups and user groups can help minimize this effort, but this requires consistent practice and coordination among administrators and precise definitions of resource groups. These processes slow down the administrative process, so administrators often avoid use of groups.
Additionally, querying the granted access to a particular group or role across an application becomes more difficult as the number of objects grows. For example, to accurately determine what permissions are granted to a user or group, administrators generally examine the permissions on every object. Since there are too many objects to query, the state of access control with respect to a particular group or user can be difficult to verify. Moreover, where more than non-trivial changes occur to an organization's resource hierarchy, such as, for example, when a human resources information management system records employee transfer to a different department, updates may be required to both the affected user objects and to any applicable ACLs, and failure to do so, can result in incorrect access permissions or an undefined state of the system. Specifically, these difficulties are due to permissions being explicitly assigned in the ACL without regard to extended properties of the protected resource.
The above-described deficiencies of today's role based security systems are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with the state of the art and corresponding benefits of some of the various non-limiting embodiments may become further apparent upon review of the following detailed description.